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Abstract 
This document proposes four optional cryptographic user interface 
suites ("UI suites") for IPsec, similar to the two suites specified 
in RFC 4308. The four new suites provide compatibility with the 


United States National Security Agency’s Suite B specifications. 
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1. Introduction 


[RFC4308] proposes two optional cryptographic user interface suites 
("UI suites") for IPsec. The two suites, VPN-A and VPN-B, represent 
commonly used present-day corporate VPN security choices and 
anticipated future choices, respectively. This document proposes 
four new UI suites based on implementations of the United States 
National Security Agency’s Suite B algorithms (see [SuiteB]). 


As with the VPN suites, the Suite B suites are simply collections of 
values for some options in IPsec. Use of UI suites does not change 
the IPsec protocols in any way. 


2. Requirements Terminology 


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
in this document are to be interpreted as described in [RFC2119]. 


3. New UI Suites 


Each of the following UI suites provides choices for ESP (see 
[RFC4303]) and for IKEvl and IKEv2 (see [RFC2409] and [RFC4306]). 
The four suites are differentiated by the choice of cryptographic 
algorithm strengths and a choice of whether the Encapsulating 
Security Payload (ESP) is to provide both confidentiality and 
integrity or integrity only. The suite names are based on the 
Advanced Encryption Standard [AES] mode and AES key length specified 
for ESP. 


IPsec implementations that use these UI suites SHOULD use the suite 
names listed here. IPsec implementations SHOULD NOT use names 
different than those listed here for the suites that are described, 
and MUST NOT use the names listed here for suites that do not match 
these values. These requirements are necessary for interoperability. 


3.1. Suite "Suite-B-GCM-128" 


This suite provides ESP integrity protection and confidentiality 
using 128-bit AES-GCM (see [RFC4106]). This suite or the following 
suite should be used when ESP integrity protection and encryption are 
both needed. 


ESP: 
Encryption AES with 128-bit keys and 16-octet Integrity 
Check Value (ICV) in GCM mode [RFC4106] 
Integrity NULL 
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IKEv1: 
Encryption AES with 128-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-256 [RFC4868] 
Hash SHA-256 [FIPS-180-2] [RFC4634] 
Diffie-Hellman group 256-bit random ECP group [RFC4753] 
Group Type ECP 


For IKEvl, Phase 1 SHOULD use Main mode. IKEvl implementations MUST 
support pre-shared key authentication [RFC2409] for interoperability. 
The authentication method used with IKEvl MAY be either pre-shared 
key [RFC2409] or ECDSA-256 [RFC4754]. 


IKEvV2: 
Encryption AES with 128-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-256 [RFC4868] 
Integrity HMAC-SHA-256-128 [RFC4868] 
Diffie-Hellman group 256-bit random ECP group [RFC4753] 
Authentication ECDSA-256 [RFC4754] 


Rekeying of Phase 2 (for IKEv1l) or the CREATE_CHILD_SA (for IKEv2) 
MUST be supported by both parties in this suite. 


3.2. Suite "Suite-B-GCM-256" 


This suite provides ESP integrity protection and confidentiality 
using 256-bit AES-GCM (see [RFC4106]). This suite or the preceding 
suite should be used when ESP integrity protection and encryption are 
both needed. 


ESP: 
Encryption AES with 256-bit keys and 16-octet ICV in GCM mode 
[RFC4106] 
Integrity NULL 
IKEv1: 
Encryption AES with 256-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-384 [RFC4868] 
Hash SHA-384 [FIPS-180-2] [RFC4634] 
Diffie-Hellman group 384-bit random ECP group [RFC4753] 
Group Type ECP 


For IKEvl, Phase 1 SHOULD use Main mode. IKEvl implementations MUST 
support pre-shared key authentication [RFC2409] for interoperability. 
The authentication method used with IKEvl MAY be either pre-shared 
key [RFC2409] or ECDSA-384 [RFC4754]. 
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IKEvV2: 
Encryption AES with 256-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-384 [RFC4868] 
Integrity HMAC-SHA-384-192 [RFC4868] 
Diffie-Hellman group 384-bit random ECP group [RFC4753] 
Authentication ECDSA-384 [RFC4754] 


Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 
MUST be supported by both parties in this suite. 


3.3. Suite "Suite-B-GMAC-128" 
This suite provides ESP integrity protection using 128-bit AES-GMAC 


(see [RFC4543]) but does not provide confidentiality. This suite or 
the following suite should be used only when there is no need for ESP 


encryption. 
ESP: 
Encryption NULL 
Integrity AES with 128-bit keys in GMAC mode [RFC4543] 
IKEv1: 
Encryption AES with 128-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-256 [RFC4868] 
Hash SHA-256 [FIPS-180-2] [RFC4634] 
Diffie-Hellman group 256-bit random ECP group [RFC4753] 
Group Type ECP 


For IKEvl, Phase 1 SHOULD use Main mode. IKEvl implementations MUST 
support pre-shared key authentication [RFC2409] for interoperability. 
The authentication method used with IKEvl MAY be either pre-shared 
key [RFC2409] or ECDSA-256 [RFC4754]. 


TKEv2: 
Encryption AES with 128-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-256 [RFC4868] 
Integrity HMAC-SHA-256-128 [RFC4868] 
Diffie-Hellman group 256-bit random ECP group [RFC4753] 
Authentication ECDSA-256 [RFC4754] 


Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 
MUST be supported by both parties in this suite. 
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3.4. Suite "Suite-B-GMAC-256" 


This suite provides ESP integrity protection using 256-bit AES-GMAC 
(see [RFC4543]) but does not provide confidentiality. This suite or 
the preceding suite should be used only when there is no need for ESP 


encryption. 
ESP: 
Encryption NULL 
Integrity AES with 256-bit keys in GMAC mode [RFC4543] 
IKEvl: 
Encryption AES with 256-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-384 [RFC4868] 
Hash SHA-384 [FIPS-180-2] [RFC4634] 
Diffie-Hellman group 384-bit random ECP group [RFC4753] 
Group Type ECP 


For IKEvl, Phase 1 SHOULD use Main mode. IKEvl implementations MUST 
support pre-shared key authentication [RFC2409] for interoperability. 
The authentication method used with IKEvl MAY be either pre-shared 
key [RFC2409] or ECDSA-384 [RFC4754]. 


TKEv2: 
Encryption AES with 256-bit keys in CBC mode 
[RFC3602] 
Pseudo-random function HMAC-SHA-384 [RFC4868] 
Integrity HMAC-SHA-384-192 [RFC4868] 
Diffie-Hellman group 384-bit random ECP group [RFC4753] 
Authentication ECDSA-384 [RFC4754] 


Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 
MUST be supported by both parties in this suite. 


4. Security Considerations 


This document inherits all of the security considerations of the 
IPsec, IKEvl, and IKEv2 documents. See [CNSSP-15] for guidance on 
the use of AES in these suites for the protection of U.S. Government 
information. 


Some of the security options specified in these suites may be found 


in the future to have properties significantly weaker than those that 
were believed at the time this document was produced. 
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3% 


6. 


6. 


IANA Considerations 


IANA has created and will maintain a registry called "Cryptographic 
Suites for IKEvl, IKEv2, and IPsec" (see [IANA-Suites]). The 
registry consists of a text string and an RFC number that lists the 
associated transforms. The four new suites in this document have 
been added to this registry after approval by an expert designated by 
the IESG. 


The new values for the registry are: 


Identifier Defined in 
Suite-B-GCM-128 RFC 4869 
Suite-B-GCM-256 RFC 4869 
Suite-B-GMAC-128 RFC 4869 
Suite-B-GMAC-256 RFC 4869 
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